Files that changed from the base of the PR and between 58cdb05 and 0506a3c.

• ably.d.ts (1 hunks)
• src/common/lib/client/restchannel.ts (1 hunks)
• src/common/lib/types/message.ts (7 hunks)

• src/common/lib/client/restchannel.ts

src/common/lib/types/message.ts (2)

12-20: LGTM!

The MessageActionArray constant provides a clear enumeration of possible message actions.

---

22-26: ⚠️ Potential issue

Improve array bounds checking and error handling

The function should handle out-of-bounds indices explicitly and return a default value or throw an error for invalid indices.

Apply this change:

function toMessageActionString(actionNumber: number): API.MessageAction {
-  if (actionNumber in MessageActionArray) {
+  if (actionNumber >= 0 && actionNumber < MessageActionArray.length) {
    return MessageActionArray[actionNumber];
  }
+  return 'message_unset';
}

Likely invalid or redundant comment.

ably.d.ts (4)

2338-2365: LGTM! Message interface changes are well-structured

The new fields added to the Message interface are well-documented and properly typed. The optional nature of these fields is appropriate as they'll only be present in specific message scenarios.

---

2386-2431: LGTM! MessageActions namespace is well-structured

The MessageActions namespace and MessageAction type are well-documented and provide a clear set of possible message actions.

---

2369-2370: ⚠️ Potential issue

Fix typo in Operation interface documentation

The comment has a typo: "update of deletion" should be "update or deletion"

Apply this diff:

- * Contains the details of an operation, such as update of deletion, supplied by the actioning client.
+ * Contains the details of an operation, such as update or deletion, supplied by the actioning client.

Likely invalid or redundant comment.

---

2383-2383: 🛠️ Refactor suggestion

Consider using a more flexible type for metadata

The current type Record<string, string> only allows string values, which might be too restrictive for complex metadata. Consider using Record<string, unknown> or a more flexible type to allow for nested objects and different value types.

-  metadata?: Record<string, string>;
+  metadata?: Record<string, unknown>;

Likely invalid or redundant comment.

Files that changed from the base of the PR and between 0506a3c and 543b360.

• src/common/lib/client/restchannel.ts (1 hunks)
• src/common/lib/types/message.ts (7 hunks)

• src/common/lib/client/restchannel.ts

src/common/lib/types/message.ts (4)

12-20: LGTM!

The MessageActionArray provides a clear enumeration of valid message actions.

---

297-305: LGTM!

The fromValues function properly handles action conversion with the new options parameter.

---

339-345: LGTM!

The new message properties are well-implemented:

• Properties are properly typed
• Serialization handles the new fields correctly
• String representation includes all new fields

Also applies to: 376-382, 405-411

---

312-312: ⚠️ Potential issue

Add type validation before type assertion

The type assertion as Record<string, unknown> assumes the input is of the correct type without validation.

Apply this change:

- result[i] = fromValues(values[i] as Record<string, unknown>);
+ const value = values[i];
+ if (!value || typeof value !== 'object') {
+   throw new ErrorInfo('Invalid message value', 40013, 400);
+ }
+ result[i] = fromValues(value as Record<string, unknown>);

Likely invalid or redundant comment.

Files that changed from the base of the PR and between 543b360 and a8dd4cf.

• src/common/lib/types/message.ts (7 hunks)

src/common/lib/types/message.ts (1)

312-312: ⚠️ Potential issue

Add type validation before type assertion

The type assertion values[i] as Record<string, unknown> could be unsafe if the input doesn't match the expected type.

- result[i] = fromValues(values[i] as Record<string, unknown>);
+ const value = values[i];
+ if (!value || typeof value !== 'object') {
+   throw new ErrorInfo('Invalid message value', 40013, 400);
+ }
+ result[i] = fromValues(value as Record<string, unknown>);

Likely invalid or redundant comment.

Files that changed from the base of the PR and between a8dd4cf and 431e31a.

• src/common/lib/types/message.ts (7 hunks)

src/common/lib/types/message.ts (2)

376-382: ⚠️ Potential issue

Add error handling for action conversion in toJSON

The action conversion could throw an error if the action is invalid. Consider handling this case gracefully.

-      action: toMessageActionNumber(this.action as API.MessageAction) || this.action,
+      action: (() => {
+        try {
+          return toMessageActionNumber(this.action as API.MessageAction) || this.action;
+        } catch (error) {
+          Logger.logAction(
+            Logger,
+            Logger.LOG_ERROR,
+            'Message.toJSON()',
+            `Invalid action: ${this.action}`,
+          );
+          return undefined;
+        }
+      })(),

Likely invalid or redundant comment.

---

28-34: ⚠️ Potential issue

Add input validation to conversion functions

The conversion functions should validate their inputs to fail fast and provide clear error messages.

 function toMessageActionString(actionNumber: number): API.MessageAction | undefined {
+  if (typeof actionNumber !== 'number' || !Number.isInteger(actionNumber) || actionNumber < 0) {
+    throw new ErrorInfo('Invalid action number', 40013, 400);
+  }
   return ReverseMessageActionMap.get(actionNumber);
 }

 function toMessageActionNumber(messageAction?: API.MessageAction): number | undefined {
+  if (messageAction && !MessageActionMap.has(messageAction)) {
+    throw new ErrorInfo('Invalid message action', 40013, 400);
+  }
   return messageAction ? MessageActionMap.get(messageAction) : undefined;
 }

Likely invalid or redundant comment.

Files that changed from the base of the PR and between 431e31a and e25751e.

• ably.d.ts (1 hunks)
• package.json (1 hunks)
• scripts/moduleReport.ts (1 hunks)
• src/common/lib/client/restchannel.ts (1 hunks)
• src/common/lib/types/defaultmessage.ts (2 hunks)
• src/common/lib/types/message.ts (7 hunks)
• src/common/lib/types/protocolmessage.ts (1 hunks)
• test/realtime/crypto.test.js (2 hunks)
• test/realtime/message.test.js (2 hunks)
• test/support/runPlaywrightTests.js (1 hunks)

• package.json
• scripts/moduleReport.ts
• src/common/lib/client/restchannel.ts
• src/common/lib/types/defaultmessage.ts
• src/common/lib/types/protocolmessage.ts

test/support/runPlaywrightTests.js (1)

71-72: LGTM: Clean implementation of grep configuration.

The addition of the grep parameter through environment variables follows testing best practices and maintains clean code structure.

src/common/lib/types/message.ts (2)

312-312: ⚠️ Potential issue

Add type validation before type assertion.

The current implementation assumes the input values are of the correct type without validation.

- result[i] = fromValues(values[i] as Record<string, unknown>);
+ const value = values[i];
+ if (!value || typeof value !== 'object') {
+   throw new ErrorInfo('Invalid message value', 40013, 400);
+ }
+ result[i] = fromValues(value as Record<string, unknown>);

Likely invalid or redundant comment.

---

405-411: ⚠️ Potential issue

Use explicit null checks in toString method.

Using truthy checks can miss zero values. Consider using explicit null checks for more accurate string representation.

-    if (this.action) result += '; action=' + this.action;
-    if (this.serial) result += '; serial=' + this.serial;
-    if (this.refSerial) result += '; refSerial=' + this.refSerial;
-    if (this.refType) result += '; refType=' + this.refType;
-    if (this.updatedAt) result += '; updatedAt=' + this.updatedAt;
-    if (this.deletedAt) result += '; deletedAt=' + this.deletedAt;
-    if (this.operation) result += '; operation=' + JSON.stringify(this.operation);
+    if (this.action != null) result += '; action=' + this.action;
+    if (this.serial != null) result += '; serial=' + this.serial;
+    if (this.refSerial != null) result += '; refSerial=' + this.refSerial;
+    if (this.refType != null) result += '; refType=' + this.refType;
+    if (this.updatedAt != null) result += '; updatedAt=' + this.updatedAt;
+    if (this.deletedAt != null) result += '; deletedAt=' + this.deletedAt;
+    if (this.operation != null) result += '; operation=' + JSON.stringify(this.operation);

Likely invalid or redundant comment.

test/realtime/crypto.test.js (1)

398-398: LGTM: Consistent handling of message actions across encryption modes.

The addition of { stringifyAction: true } option in both 128-bit and 256-bit msgpack tests ensures proper stringification of the new message action field during decoding. This change aligns with the PR's objective of supporting operations in messages.

Let's verify the consistency of this change across the codebase:

Also applies to: 443-443

✅ Verification successful

Let me gather more context about the stringifyAction option usage to ensure completeness of the verification.

---

The stringifyAction option is correctly used in the crypto tests

The verification confirms that the stringifyAction option is being used appropriately in the crypto tests. The codebase shows:

1. The option is part of the Message class's design, converting numeric action values to their string representations using MessageAction enum.
2. It's consistently used across the codebase in message decoding scenarios:
   • In protocol message handling: messageFromValues(messages[i], { stringifyAction: true })
   • In message decoding: fromValues(encoded, { stringifyAction: true })
   • In the crypto tests for both 128-bit and 256-bit encryption

The implementation in the crypto tests aligns with the established pattern for handling message actions throughout the codebase.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the usage of stringifyAction option in message decoding
# Test: Search for other message decoding calls that might need the same option

# Look for Message.fromValues calls
ast-grep --pattern 'Message.fromValues($$$)'

# Look for msgpack.decode calls
rg 'msgpack\.decode'

Length of output: 1304

---

Script:

#!/bin/bash
# Search for stringifyAction usage across the codebase
rg "stringifyAction" -B 2 -A 2

# Look for Message class definition to understand the option handling
ast-grep --pattern 'class Message {
  $$$
}'

# Search for message action related code
rg "MessageAction" -B 2 -A 2

Length of output: 16492

test/realtime/message.test.js (1)

1278-1315: Verify the consistency of message action values.

The test cases assume specific numeric values for actions (e.g., 1 for 'message.create', 2 for 'message.update'). Let's verify these values are consistent with the implementation.

✅ Verification successful

The verification results show that the message action values are defined in src/common/lib/types/message.ts using a zero-based index array MessageActionArray. The array defines the actions in order: 'message.unset' (0), 'message.create' (1), 'message.update' (2), which perfectly matches the test cases' assumptions where 'message.create' corresponds to 1 and 'message.update' corresponds to 2.

Let me verify one more aspect - the actual usage of these maps in the message implementation:

---

Test cases correctly reflect the message action handling implementation

The verification confirms that the test cases are consistent with the implementation:

1. The action values are correctly defined in MessageActionArray with 'message.create' at index 1 and 'message.update' at index 2
2. The Message class implementation in src/common/lib/types/message.ts shows:
   • toJSON() converts string actions to numbers using toMessageActionNumber
   • toString() directly uses the action value (string or number)

This matches the test cases' expectations where:

• Numeric action 1 maps to 'message.create'
• Numeric action 2 maps to 'message.update'
• String actions are preserved in toString() but converted to numbers in toJSON()

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify message action values are consistent across the codebase

# Test: Search for action enum/constant definitions
echo "Searching for message action definitions..."
rg -A 5 "(?:enum|const)\s+(?:Message)?Action"

# Test: Search for specific action string literals
echo "Searching for action string literals..."
rg -A 2 "(?:message\.create|message\.update)"

Length of output: 2533

---

Script:

#!/bin/bash
# Search for the message implementation that uses these action maps
ast-grep --pattern 'class $_ {
  $$$
  toString() {
    $$$
  }
  $$$
}'

# Also check for toJSON implementation
ast-grep --pattern 'class $_ {
  $$$
  toJSON() {
    $$$
  }
  $$$
}'

Length of output: 6443

ably.d.ts (4)

2338-2365: LGTM: Message interface changes are well-documented and properly typed.

The new fields (action, serial, refSerial, etc.) are correctly marked as optional since they may not be set when building a message, while being required in InboundMessage type. This aligns with the materialization enhancement objectives.

---

2435-2435: LGTM: InboundMessage type correctly requires new fields.

The addition of 'serial' and 'action' to the required fields is appropriate as these will be set on all messages across all namespaces, as confirmed in previous discussions.

---

2380-2383: 🛠️ Refactor suggestion

Consider using a more flexible type for metadata.

The current type Record<string, string> restricts metadata values to strings only. Consider using Record<string, unknown> or a more flexible type to allow for structured metadata.

Apply this diff to allow more flexible metadata values:

-  metadata?: Record<string, string>;
+  metadata?: Record<string, unknown>;

Likely invalid or redundant comment.

---

2369-2370: ⚠️ Potential issue

Fix typo in Operation interface comment.

The comment should read "update or deletion" instead of "update of deletion".

Apply this diff to fix the typo:

- * Contains the details of an operation, such as update of deletion, supplied by the actioning client.
+ * Contains the details of an operation, such as update or deletion, supplied by the actioning client.

Likely invalid or redundant comment.